The technology described herein relates to a method of and apparatus for processing graphics, and in particular to such a method and apparatus for use in a tile-based graphics processing system.
As is known in the art, graphics processing is normally carried out by first splitting the scene to be displayed into a number of similar basic components or “primitives”, which primitives are then subjected to the desired graphics processing operations. The graphics “primitives” are usually in the form of simple polygons, such as triangles, and are usually described by defining their vertices.
Many graphics processing systems use so-called “tile-based” rendering. In tile-based rendering, the two-dimensional render output or target (i.e. the output of the rendering process, such as an output frame to be displayed) is rendered as a plurality of smaller area sub-regions, usually referred to as “tiles”. The tiles are each rendered separately (typically one-after-another). The rendered tiles are then recombined to provide the complete rendering output (e.g. frame for display). In such arrangements, the render target (output) is typically divided (by area) into regularly-sized and shaped rendering tiles (they are usually e.g., squares or rectangles) but this is not essential.
Other terms that are commonly used for “tiling” and “tile-based” rendering include “chunking” (the rendering tiles are referred to as “chunks”) and “bucket” rendering. The terms “tile” and “tiling” will be used hereinafter for convenience, but it should be understood that these terms are intended to encompass all alternative and equivalent terms and techniques.
The advantage of such tile-based rendering is that primitives that do not appear in a given tile do not have to be processed for that tile, and therefore can be ignored when the tile is processed. This allows the overall amount of graphics processing necessary for a given render output to be reduced.
In a tile-based rendering system, it is accordingly usually desirable to be able to identify and know those primitives that are actually present in a given rendering tile so as to, e.g., avoid unnecessarily rendering primitives that are not actually present in a tile. In order to facilitate this, it is known to prepare for each rendering tile a list of the primitives to be rendered for that rendering tile (e.g. that will appear in the tile). Such a “primitive-list” (which can also be referred to as a “tile list”) identifies (e.g. by reference to a primitive indicator) the primitives to be rendered for the tile in question.
The process of preparing primitive lists for each tile to be rendered basically involves determining the primitives that should be rendered for a given rendering tile. This process is usually carried out by determining (at a desired level of accuracy) the primitives that intersect (i.e. that will appear (at least in part) within) the tile in question, and then preparing a list of those primitives for future use by the graphics processing system. (It should be noted here that where a primitive falls into more than one tile (as will frequently be the case), it is included in the tile list for each tile that it falls within.) In effect, each tile can be considered to have a bin (the primitive-list) into which any primitive that is found to fall within (i.e. intersect) the tile is placed (and, indeed, the process of sorting the primitives on a tile-by-tile basis in this manner is commonly referred to as “binning”).
As known in the art, the process of determining the primitives that should be listed (rendered) for any given rendering tile can be carried out at varying levels of precision, for example depending on efficiency optimisations for different parts of the tiling and rendering processes. For example, at the most precise level, it could be determined exactly which tiles a given primitive will appear at least in part in, and the primitive then included in the primitive lists for those tiles only. This is commonly referred to as “exact” binning.
FIG. 1 illustrates the exact binning process. As shown in FIG. 1, a render target in the form of a frame 1 to be displayed is divided into sixteen regularly sized tiles 2 for rendering purposes. It is then determined for each primitive in the frame, which tile or tiles the primitive actually appears (falls) within. The primitive is added to the primitive-list for each tile that it is found to fall within. Thus, taking the example shown in FIG. 1, the primitive 3 is added to the primitive-list for tile 4, the primitive 5 is included in the primitive-list for tiles 6 and 7, the primitive 8 is included in the primitive lists for tiles 9, 10, 11 and 12, and the primitive 13 is included in the primitive-list for tile 12. (It should be noted here that FIG. 1 shows only a few tiles and primitives for clarity purposes. As will be appreciated by those skilled in the art, in an actual graphics processing operation, there will typically be many more primitives and tiles.)
It is also known to prepare primitive-lists with a lower precision than is achieved with exact binning. This can be useful to, e.g., simplify the preparation of the primitive-lists. One common “less precise” binning technique is “bounding box” binning. In this case, a so-called “bounding box” is drawn around a primitive or a set of primitives, and then the tiles covered by the bounding box are determined. The primitive or primitives that the bounding box represents (i.e. that are encompassed by the bounding box) are then listed (binned) for each tile that the bounding box has been found to cover (at least in part).
Once lists of primitives to be rendered (primitive-lists) have been prepared for each rendering tile in this way, the primitive-lists are stored for use, e.g., to allow the system to identify which primitives need to be considered (and rendered) when the tile in question is rendered.
Such tile-based rendering arrangements have been found to work well, as they can, for example, help to avoid primitives still being processed for regions of the render target where they are not present.
However, one drawback with the need to prepare and store primitive-lists identifying the primitives to be rendered for each tile is that depending on the distribution of the primitives for a given, e.g., frame to be rendered, the primitive-lists for different tiles to be used for the frame can be very different sizes, as can the primitive lists for tiles for different frames. This means that, e.g., a given render output or tile may have significantly different memory requirements for storing its primitive list(s) as compared to other tiles or render outputs.
The Applicants have accordingly already proposed in their UK Patent No. 2433014 an improved tile-based rendering system, which prepares primitive lists both for single rendering tiles, and primitive lists for render target areas comprising more than one tile (i.e. primitive lists that encompass more than one rendering tile (and thereby, in effect, a larger area) of the output to be generated). In other words, as well as preparing lists of primitives that are exclusive to single rendering tiles only, primitive-lists that can and will be used for plural rendering tiles in common can be and are prepared.
As discussed in the Applicant's earlier patent, preparing different render target “area” primitive lists has a number of advantages, such as allowing the amount of memory that is used for the primitive lists to be varied, and facilitating better control over and knowledge of the memory usage requirements for the primitive listing process.
In the Applicant's earlier patent, the primitives are basically sorted into the primitive lists for different sized areas of the render target so as to limit the number of different primitive lists a given primitive will be listed in. This helps to control the amount of memory that will be needed for the primitive lists.
However, the Applicants have now recognised that some additions and variations to the scheme described in their earlier patent can, at least in certain circumstances, be advantageous.
Like reference numerals are used for like features throughout the drawings, where appropriate.